Earlier in the spec, implementations are required to halt when encountering infinite cycles.

How would one break such a cycle?

I didn't intend to imply that one could somehow continue evaluating the schema. I'll reword to make it more clear that it should stop evaluation when it detects a cycle.

When would we not want to allow that? I think we should upgrade this to a MUST.

I think (not in front of a computer currently) that normalization is a requirement of the sections on reference resolution.

That said, I wouldn't be opposed to being more strict around preventing overwrites.

Would a MUST-level requirement be appropriate here, or would it fit more in one of the main body sections?

First of all ...

Would a MUST-level requirement be appropriate here, or would it fit more in one of the main body sections?

Right. The Security Considerations section should be an analysis of the security considerations both mitigated and not mitigated by requirements as defined in the specification. It should not make normative statements, but can reference parts of the spec that do.

When would we not want to allow that? I think we should upgrade this to a MUST.

There are two "shoulds" in this sentence, so I'm not sure which one (or both) are being referred to.

Implementations should consider rejecting schemas that have identifiers (including embedded schema identifiers) that conflict with registered schemas

A reasonable alternative could be to ignore the schema and use the registered one instead (perhaps with a warning). A scenario where I think this might make sense is with a bundled schema that includes a common schema because it might be used in a variety of implementations and doesn't know if the schema will be registered or not. If the implementation doesn't have that schema registered, then it's available in the bundle. If the implementation does have it registered, it should use the registered version. I think there's a variety of different situations and use cases where not rejecting the schema could make sense. I'd like implementations to be able to provide users with the ability to choose how this should be handled. But, suggesting that they should be rejected is, I think, I good "secure by default" behavior.

and should apply consistent URI normalization and comparison logic to detect and
prevent conflicts.

Looking into this, I just noticed the following from RFC 3987

Applications using IRIs as identity tokens with no relationship to a protocol MUST use the Simple String Comparison (see section 5.3.1). All other applications MUST select one of the comparison practices from the Comparison Ladder (see section 5.3

JSON Schema describes our use of IRIs as identity tokens, not locators, which means implementations should limit themselves to Simple String Comparison. That's not what our spec currently says. It says to use the normalization procedure defined in 5.3, which isn't quite correct either. We'd need to be more specific about which comparisons to use. For example, we wouldn't require scheme-based or protocol-based normalization because it would be too onerous a requirement for implementers to implement scheme-based requirements for any scheme they might encounter.

From a security perspective, it doesn't matter what normalization is performed, only that it's consistent. Maybe that's the update we should make for now and discuss what comparison/normalization should be required in the spec in a separate issue.

I can think of a clear usecase for this.
It may be that implementations have chosen poor architecture and only allow a single instance of the implementation.
Say I have a JSON Schema, and I want to evaluate the outcome if I change a part of one of the referenced schemas? If it was already registered with an ID, and I want to override that, I should be able to.

I think that comes down to an implementation option to allow it. The default behavior should be to reject an overwrite attempt.

We should update this to use "extension" language since we've removed "vocabulary".